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SYSTEM AND METHOD FOR MANAGING 
CACHABLE ENTITIES 

BACKGROUND 

1. Technical Field 

The present invention relates generally to caching infor- 
mation in a data processing system and, in particular, to a 
system and method for managing cachable entities by ana- 
lyzing program (source) code to delect one or more state- 
ments which may affect a desirability of performing one or 
more cache transactions such as storing an entity in cache 
and/or invalidating or updating cached entities. 

2. Description of Related Art 

Caching is a technique which is commonly utilized for 
improving performance on many computer systems. For 
example, in an object-oriented computing environment, 
caching an object can minimize the cost for fetching or 
creating an object since it is only incurred once. Specifically, 
subsequent requests for a cached object can be satisfied from 
the cache, a process which incurs significantly less overhead 
than recalculating the object or fetching it from a remote 
location. 

Object-oriented and other database applications often 
issue queries to databases. These queries can be expensive to 
make in terms of, e.g., computation time and memory. 
Caching techniques may be utilized for reducing the over- 
head associated with issuing queries by caching query 
results such that the query need only be issued once. 
Subsequent requests for the same query would be able to 
access the corresponding query results from the cache. 

A key problem associated with caching query results in 
many data processing environments is keeping the cache 
information updated after the database content is modified. 
In particular, if the database modification affects one or more 
cached query results, the cache should be updated to reflect 
the changes, otherwise, incorrect data could be returned. 
Due to the difficulty in efficiently keeping the cache updated, 
database systems typically do not cache query results. 
Therefore, there is a need for a system and method for 
automatically maintaining and updating cache content in a 
data processing system in response to a change in the 
underlying data content. 

SUMMARY OF THE INVENTION 

The present invention is directed to a system and method 
for managing cachable entities (i.e., entities stored in a cache 
and/or entities which may be stored in a cache) in a data 
processing application.. In one aspect of the present 
invention, a method for managing cachable entities com- 
prises the steps of: 

analyzing program code to determine if there is at least 
one statement which affects a desirability of performing 
at least one cache transaction; and 

performing the at least one cache transaction if it is 
desired. 

In another aspect, the present invention provides a pro- 
gram analysis tool for statically analyzing program code to 
locate points where object state changes occur, where 
objects are created and where objects are deleted, and then 
generating regularized dependencies at such points for and 
employing the dependencies to invalidate dependent cached 
queries. 

In yet another aspect, the present invention provides a 
mechanism for generating query specific keys which are 
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employed to insert query results into and retrieve query 
results from a dependency managed cache. 

In another aspect, the present invention provides a mecha- 
nism for selected cache repopulation of invalidated queries. 
5 In yet another aspect, the present invention provides a 
mechanism for generation of regularized dependencies at the 
object query points and for attaching them to query results 
inserted into a dependency managed cache. 

In another aspect, the present invention provides a mecha- 
10 nism to insert/retrieve query results into/from a dependency 
managed cache. 

In yet another aspect, the present invention provides a 
mechanism to delegate requests for query results to an 
underlying object query service when necessary. 
15 In another aspect, the present invention provides a mecha- 
nism for selected cache initial population of anticipated 
queries. 

One advantage of the present invention is that it improves 
response time for queries issued multiple times. Improve - 
20 ment is accomplished by obtaining results more efficiently 
from a dependency managed cache, thus bypassing the 
normally used but usually less efficient object query machin- 
ery. 

These and other aspects, features and advantages of the 
25 present invention will become apparent from the following 
detailed description of preferred embodiments, which is to 
be read in connection with the accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

30 FIG. 1 is a block diagram of a system for managing 
cachable entities in accordance with an embodiment of the 
present invention; 

FIG. 2 is a flow diagram of method for managing cachable 
35 entities during run-time execution of a data processing 
application in accordance with one aspect of the present 
invention; 

FIG. 3 is a flow diagram of a program analysis process for 
managing cachable entities in accordance with one aspect of 
40 the present invention; 

FIG. 4 is a flow diagram of a method for processing a 
query utilizing cached query results in accordance with one 
aspect of the present invention; 

FIG, 5 is an object dependence graph in accordance with 
45 one aspect of the present invention; and 

FIG. 6 is a flow diagram of a general method for man- 
aging cachable entities in accordance with another aspect of 
the present invention. 

50 DETAILED DESCRIPTION OF PREFERRED 

EMBODIMENTS 

It is to be understood that the system elements described 
herein may be implemented in various forms of hardware, 

55 software, firmware, special purpose processors, or a com- 
bination thereof. Preferably, the present invention is imple- 
mented in software as an application program tangibly 
embodied on a program storage device. The application 
program may be uploaded to and executed by a machine 

60 having any suitable architecture. Preferably, the machine is 
implemented on a computer platform comprising hardware 
such as one or more central processing units (CPU), a 
random access memory (RAM), and input/output (I/O) 
interface(s). The computer platform also includes an oper- 

65 ating system and microinstruction code. The various pro- 
cesses and functions described herein may either be part of 
the microinstruction code or part of an application program 
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(or a combination thereof) which is executed via the oper- 
ating system. In addition, various other peripheral devices 
may be connected to the computer platform such as an 
additional data storage device and a printing device. 

It is to be further understood that, because the constituent 
system components and method steps depicted in the accom- 
panying Figures are preferably implemented in software, the 
actual connections between the system modules (or the 
process steps) may differ depending upon the manner in 
which the present invention is programmed. Given the 
teachings herein, one of ordinary skill in the related art will 
be able to contemplate these and similar implementations or 
configurations of the system and method described herein. 

It is to be further understood that the present invention 
may be implemented in any object-oriented and database 
data processing systems for managing cachable entities. 
Notwithstanding that the invention described herein may be 
employed in various data processing systems, for purposes 
of illustration, the system and methods set forth herein (as 
well as the exemplary program code) will be discussed in 
relation to International Business Machines' WebSphere™, 
a middleware product that can be used to design, develop 
and deploy distributed object-oriented applications, in which 
the cachable entities are query results. One aspect of the 
WebSphere™ system is currently implemented utilizing 
C++programming language source code. With IBM's Web- 
Sphere™ system, an object creation function and an object 
deletion function are referred to as a "create" method and a 
"delete" method, respectively. In addition, an object state 
change function is referred to as a "set attribute method/' 
Also, a query function for retrieving a collection of objects 
is referred to as a "find" method. Although these terms will 
be used in the following description, it is to be understood 
that such terms also refer to analogous functions of other 
data processing systems in which the present invention may 
be employed. 

Referring now to FIG. 1, a block diagram illustrates a data 
processing system for managing a cache of query results in 
accordance with an embodiment of the present invention. It 
is to be understood that although the system depicted in FIG. 
1 illustrates the various modules which may be utilized for 
implementing the present invention, the various modules 
may be employed at different times during program execu- 
tion (e.g., either prior to or at compile time and/or during 
run-time execution). The data processing system 100 
includes an application program interface (API) 101 for 
providing communication between an outside entity and the 
system 100. For instance, in a client-server configuration, 
the API 101 may be implemented as one or more servers 
each having a suitable application program for processing 
programmatically-formulated statements thereby allowing, 
e.g., remote clients to interact with the data processing 
system 100 over a network. In addition, the API 101 may be 
a computer monitor utilizing a graphical user interface 
(GUI) suitable for inputting user- formulated commands and 
otherwise allowing human-centric type clients to commu- 
nicate with the system 100, as well as for displaying 
information, e.g., query results. 

A query processor module 102 analyzes program code to 
detect programmatically-formulated (as well as user- 
formulated) query statements (which are input via the API 
101) during pre-compile time (program analysis execution) 
and then processes query statements during program execu- 
tion run-time (as described below in detail). Similarly, 
during pre-compile time, a modification processor module 
103 analyzes program code to detect programmatically- 
formulated (as well as user-formulated) statements (which 
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are input via the API 101) requesting modification of the 
data content of database 104, and then processes the code 
during run-time (as described in detail below) for effecting 
the requested modification. For purposes of the following 
5 description, it is assumed that the database 104 stores all of 
the relevant data, as well as a plurality of objects which are 
created from the data and other objects (collectively, referred 
to as "entities"). 

The data processing system 100 also includes a cache 105 
10 which is managed by cache manager module 106. The cache 
105 is preferably implemented in software (i.e., managed 
memory, backed by disk) although one skilled in the art may 
envision other cache implementations depending on the 
application (e.g., a database cache such as IBM's DB2 
35 database or a processor cache such as the cache in IBM's 
RS/6000 line of computers). The cache manager module 106 
is responsible for managing the cache 105 by, for example, 
searching for cached query results and automatically invali- 
dating cached query results which are affected due to object 
20 and/or data modification. 

The cache manager module 106 comprises a plurality of 
modules, each of which are employed either during pre- 
compile time or run- time, For example, during pre-compile 
time, an invalidation key format module 107 generates an 
25 invalidation key for each "set", "create" and "delete" state- 
ment which is detected (by the data modification processor 
103) during program analysis, each invalidation key having 
a key format based on the detected statement. For each 
detected "set", "create" and "delete" method, a code aug- 
mentation module 108 generates and injects code into the 
target method, which is subsequently compiled and executed 
to calculate the key for invalidating dependent cached query 
results. 

35 A query key format module 114 generates a query key for 
each "find" statement detected during program analysis, 
each query key having a key format based on the detected 
statement. For each detected "find" statement, the code 
augmentation module 108 generates and injects code into 

4(J the method, which is subsequently compiled and executed to 
generate a cache query key for searching the cache 105. 

The cache manager module 106 also includes modules 
which are employed during run-time. For example, after the 
augmented code injected into a "find" method is compiled, 

45 a query key generator module 109 will execute the compiled 
code to calculate the cache query specific key incorporating 
run-time query data (attribute values). The cache query keys 
are employed to insert query results into, and retrieve query 
results from, the dependency managed cache 105. Similarly, 

50 after the augmented code is injected into the "set", "delete" 
or "create" methods, an invalidation key generator module 
110 will execute the compiled code to calculate a specific 
invalidation key based on the run-time attribute values for 
invalidating cached query results dependent on the state 

55 changes of the attribute values. The invalidation key gen- 
erator module 110 also produces regularized dependencies 
which are added to query results stored in the cache 105. 
These dependencies are used in conjunction with the invali- 
dation keys to invalidate cached query results having the 

60 corresponding dependencies. 

Other components of the cache manager module 106 
which are employed during run-time include a query result 
duplication module 111, which replicates the query results 
(for output or further processing) that are either located in 

65 cache 105 by the query processor 102 using the calculated 
query key or generated by the query processor 102 when the 
cache does not contain corresponding query results. A query 
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key/dependency mapping module 113 operates during run- 
time to map the relationship between the generated query 
keys and the regularized dependencies. A query result 
invalidation/repopulation module 112 operates to invalidate 
cached query results which are dependent on modified data $ 
and/or objects using the invalidation keys and to repopulate 
invalidated cached query results. Each of the functions of the 
above system elements will be described in further detail 
below. 

Referring now to FIG. 2, a flow diagram illustrates 1Q 
method for managing a cache of query results during run- 
time execution in accordance with one aspect of the present 
invention. The process begins with program initialization 
(i.e., initialization of the cache manager module) (step 199) 
which initializes (repopulates) the cache of query results 15 
based upon certain initialization considerations (such as 
frequently used query results from prior executions, pro- 
gram environment, etc.) The process continues with pro- 
gram execution (step 200) until a "set attribute" or "create" 
or "delete" operation is encountered (step 201) or a "find" 2 q 
operation is encountered (step 202). If a "set attribute" or 
"create" or "delete" operation is encountered (affirmative 
result in step 201), the cache will be searched and dependent 
cached query results will be invalidated using the corre- 
sponding invalidation keys (step 203). In particular, invali- 25 
dation is performed by discarding query, results, if any, 
contained in the cache which are dependent on the change in 
attribute value, or the creation or deletion of an instance of 
an object. Invalidation may result, for example, in one of the 
following: (i) a purge from the cache; (ii) a purge from the 30 
cache followed by repopulation of the cache; or (iii) updat- 
ing the cache (e.g., for a delete operation, removing the 
object from each dependent query result). Once all depen- 
dent query results have invalidated, program control returns 
to normal program execution (return to step 200). 35 

If a "find" operation is encountered (affirmative result in 
step 202), a query key is calculated (step 204). The query 
key is utilized for accessing and updating information con- 
tained in the cache. The query key is based upon object class, 
subject attributes of the query, and possibly their associated 4 q 
desired values. The calculated query key is then used to 
search the cache and locate associated query results in the 
cache (step 205). A determination is made as to whether 
query results satisfying the query already exist in the cache 
(step 206). If it is determined that the cache does contain 45 
results for the query (affirmative determination in step 206), 
the cached query results are duplicated and output for 
display and/or further processing (step 207). The process of 
duplicating the cached query results is performed by utiliz- 
ing the calculated cache key (from step 204) to retrieve the 50 
results for the query from the cache and making a copy to 
provide to the running program. 

On the other hand, if it is determined that the cache does 
not contain results for the query (negative determination in 
step 206), the original query is processed in normal manner 55 
to obtain query results (step 208), absent the efficient cache 
method described herein. The query results are then stored 
in the cache using the previously calculated cache key (step 
209). The stored query results are then duplicated and output 
for display and/or further processing (step 207). Program 60 
control then returns to normal program execution (step 200). 

It is to be understood that prior to run-time execution of 
the program (as depicted in FIG. 2) whereby the query 
results are efficiently cached and properly invalidated, a 
program analysis process must first be performed whereby 65 
additional program logic is incorporated into the target 
application in a methodical, patterned, regularized way. 



Referring now to FIG. 3, a flow diagram illustrates a 
program analysis process for managing a cache of query 
results in accordance with one aspect of the present inven- 
tion. The process depicted in FIG. 3 will be referred herein 
as the ALPACA (automated logical program analysis and 
code augmentation) process. The ALPACA process begins 
with program analysis execution (step 300) until a "set 
attribute" method is detected (step 301), a "create" or 
"delete" method is detected (step 302), or until a "find" 
method is detected (step 306), until all relevant statements 
have been scrutinized, at which time the code is compiled. 
It is to be understood that the present invention may be 
configured to detect statements in the form of source code, 
assembly code, machine code, and structured query lan- 
guage (SQL) code. 

When a "set attribute" method is detected (affirmative 
determination in step 301), program analysis control flows 
to generate code for generating an invalidation key (via the 
invalidation key format module 107, FIG, 1), which may be 
structured in accordance with the class name and method 
name of the subject attribute, together with the present and 
future values of the subject attribute (303). It is to be 
understood that the invalidation key which is generated for 
a "set attribute" method is partially static because values of 
the invalidation key such as the class name and the attribute 
name are known at compile time, and partially dynamic 
since the values such as the previous attribute value and a 
new attribute value are only known during run-time execu- 
tion after the code is compiled. After the invalidation key 
format is generated, augmented program code for calculat- 
ing the invalidation key is generated and injected into the 
"set attribute" method (step 304) (via the code augmentation 
module 108, FIG. 1). As discussed above, the augmented 
code is subsequently compiled and executed to calculate the 
invalidation key during run -time execution for cache invali- 
dation (i.e., step 203, FIG. 2). Control then returns to 
continue program analysis (return to step 300) until the 
entire relevant portions of the program have been examined, 
at which time the code is compiled. 

When a "create" or "delete" method is detected 
(affirmative determination in step 302), program analysis 
control flows to generate code for generating an invalidation 
key (via the invalidation key format module 107, FIG. 1) 
which may be structured in accordance with the class name 
and method name of the subject operation together with the 
present and/or future value(s) of all applicable subject object 
attributes (step 305). It is to be understood that the invali- 
dation key which is generated for a "create" or "delete" 
method is partially static because values of the invalidation 
key such as the class name and the method name are known 
at compile time, and partially dynamic since the previous 
(when deleting) and new (when creating) attribute values are 
only known during run-time execution after the code is 
compiled. After the invalidation key format is generated, 
augmented code for calculating the invalidation key is 
generated and injected into the "create" and "delete" meth- 
ods (step 304) (via the code augmentation module 108, FIG. 

1) . As discussed above, the augmented code is subsequently 
compiled and executed to calculate the invalidation key 
during run-time for cache invalidation (i.e., step 203, FIG. 

2) . Control then returns to continue program analysis (return 
to step 300) until the entire relevant portions of the program 
have been examined, at which time the code is then com- 
piled. 

It is to be appreciated that the invalidation keys are used 
to locate any cached query results which are dependent upon 
attribute state changes, where the term "dependent" refers to 
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a change in the query results with respect to the result of the 
create, delete, or set operation in progress. 

When a "find" method is detected (affirmative determi- 
nation in step 306), program analysis control flows to 
generate code and inject the code into the "find" method 
(step 307) which is subsequently complied and executed 
during run-time for calculating the query specific key in 
accordance with class and method name, the evaluation 
method, and the query data (i.e., step 204, FIG. 2). After the 
"find" method code is augmented, control returns to con- 
tinue program analysis (step 300) until the entire relevant 
portions of the program have been examined, at which time 
the code is compiled. 

The ALPACA method of FIG. 3 will now be explained in 
further detail with reference to the blocks of exemplary 
program code illustrated below. 

By way of example, the following block of program code 
illustrates original programmer supplied source code that 
represents some portion of an implementation of an object 
where it is expected that all attribute state changes occur 
through a "set attribute" method having a patterned signa- 
ture: 

void class A: attribute 1 (string sVat){/*"set attribute 1"*/ 
iDataObjcct->attributcl (sVal); 

} (D 

Briefly, the "set attribute" pattern recognized in the above 
program code is as follows: the method returns void; the 
class name and method name are separated by ::; and exactly 
one parameter is passed into the method specifying the new 
value for the attribute. It is to be understood that other 
recurring patterns designated as "set attribute" methods are 
possible and even likely. 

The following block of program code illustrates code 
augmentation of the above "set attribute" method for invali- 
dating cached query results based on attribute state modifi- 
cation in accordance with one aspect of the present inven- 
tion: 

void class A: :attributel (string sVal){/* "set attributel"7 
strmg__vaf sVar01d=classA::attributel( ); 
string_var sVarNew=duplicate(sVaI); 

qCache::invalidate("set", "classA", "attribute V^VaiOld, SVar- 
New); 



iDataObject->attributel (sVal); 
} 



(la) 



As shown, the original programmer supplied source code is 
augmented with additional code (shown in italics) in accor- 
dance with step 304 of FIG. 3 in order to invalidate cached 
queries dependent upon attribute state changes (step 203 of 
FIG. 2). Specifically, during the ALPACAprocess (FIG. 3), 
each method signature is examined to determine whether or 
not it is a "set attribute" method. The sample block of 
program code (1) has such a signature and, consequently, the 
ALPACA process generates updated program code for the 
"set attribute" method, which results in the updated program 
code block (la). These changes are then compiled into the 
program. Subsequently, during run-time execution, the 
newly injected code will cause invalidation of query results 
from the cache which become stale due to the subject "set 
attribute" state change occurrence. As indicated above, 
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invalidation may result, for example, in one of the follow- 
ing: (i) a purge from the cache; (ii) a purge from the cache 
followed by repopulation of the cache; or (iii) updating the 
cache. 

To "update" the cache, further information would be 
necessary for q Cache "invalidate, namely, a reference to the 
changed object itself, so that the object could be added/ 
removed from the cached queries as appropriate. 

Next, the following exemplary program code block illus- 
trates original programmer supplied source code that repre- 
sents some portion of an implementation of an object where 
it is expected that all requests to create or delete objects of 
a subject class are made through a "create" and a "delete" 
method, respectively, each having a patterned signature: 



class A "object class AHome::create() { 

classA::objcct target = iDataObjcct->createQ; 
return(targct); 

} 

void classAHomc:: delete (class A:: object target) { 
tDataObject->delete(targct); 

} 



(2) 



(3) 



25 Briefly, the "create" pattern recognized in this sample is as 
follows: the method returns a value which is the represen- 
tation of the newly created object; the class name and 
method name are separated by :: ; the class name contains 
the string "Home" and a string representing the subject 

30 class; the method name contains the string "create"; and no 
parameters are passed into the method. It is to be appreciated 
that other recurring patterns designated as "create" methods 
are possible and even likely. 

Similarly, the "delete" pattern recognized in this sample is 

35 as follows: the method returns void; the class name and 
method name are separated by :: ; the class name contains 
the string "Home" and a string representing the subject 
class; the method name contains the string "delete"; and 
exactly one parameter is passed into the method specifying 

40 the object to be deleted. It is to be appreciated that other 
recurring patterns designated as "delete" methods are pos- 
sible and even likely. 

The following blocks of program code illustrate code 
augmentation for invalidating cached query results based on 

45 object creation and object deletion, respectively, in accor- 
dance with one aspect of the present invention: 



classA::object class AHo me :xreateQ { (2a) 
qCache-invalidatefcreate", "classA", *"\ ""); 
classA::object target = iDataObject->creale(); 
returnf target); 

} 

void classAHome::delete(classA::object target) { (3a) 
55 qCache-mvalidateCdelete", "classA", "", ""); 

iDataObject->delete(target); 

} 



As shown, the original programmer supplied source code is 
60 augmented with additional code (shown in italics) in accor- 
dance with step 304 of FIG. 3 in order to invalidate cached 
queries dependent upon object creation and deletion changes 
(step 203 of FIG. 2). Specifically, during the ALPACA 
process, each method signature is examined to determine 
65 whether or not it is a either a "create" method or a "delete" 
method. In the above sample blocks of program code (2) and 
(3), exactly one of each occurs and, consequently, the 
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ALPACA process generates updated program code for the 
"create" and "delete" methods, which results in the updated 
program code blocks (2a) and (3a), respectively. Tliese 
changes are then compiled into the program. Subsequently, 
during run-time, execution of the newly injected code will 
cause invalidation of query results from the cache which 
become stale due to subject "create" or "delete" state change 
occurrence. Again, invalidation may result, for example, in 
one of the following: (i) a purge from the cache; (ii) a purge 
from the cache followed by repopulation of the cache; or (iii) 
updating the cache. 

To "update" the cache, further information would be 
necessary for qCache:: invalidate, namely, a reference to the 
created/deleted object itself, so that the object could be 
added/removed from the cached queries as appropriate. 

Next, the following exemplary blocks of program code 
illustrate original programmer supplied source code which 
represents some portion of an implementation of an object 
where it is expected that all queries to locate objects or sets 
of objects are made through "find" methods having both a 
patterned signature and a patterned "object query tech- 
nique": 



classA::object[] class AHome::findBy Attribute! (string al){ (4) 
classA::object[] retVal; 
string_var sQuery - "attribute 1 — " + al; 
retVal = iDataObject->cval (sQucry); 
return(rctVal); 

} 

classA::object[] classAHomc::findbyAttributc2(int a2) { (5) 
classA::object[] retVal; 

string__var sQucry = "attribute 2 ==" + intToString(a2); 
retVal = iData Object- ;>eval(sQuery); 
return (retVal); 

} 



classA::object[] class AHome::findByAt tribute 1 Or Attribute2(string (8) 
al, int a2) { 

classA::objecr{] retVal; 

string_var sQl = "attributcl «»" + al; 

string_var sQ2 - "attribute + intToString(a2); 

string_var sQuery - sQl + "OR"+ sQ2; 

retVal « iDataObject->eval(sQucry); 

returnfrctVal); 

} 
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classA::object(] classAHome::findByAttribute3(classB::object (6) 
a3){ 

classA::object[] retVal; 

string_var sQuery = "attribute3 ==" + objectTold(a3); 

retVal = iDataObject->eval(sQuery); 40 

return(retVal); 

} 

classA::object[] (7) 
ciassAHome::rlndByAttributel And Attribute2 (string al, int a2) { 

classA::object[] retVal; 45 

string_var sQl « "attribute 1 =" + al ; 

string_var sQ2 = "attribute2 ==" + intToString(a2); 

string„var sQuery - sQl + "AND"+ sQ2; 

retVal = iData Ob ject->eval (sQuery); 

return(retVal); 

} 



50 



55 



60 



Briefly, the "find" pattern recognized in each of these 
samples is as follows: the method returns a value which is 
the representation of a collection of objects of the subject 
class; the class name and method name are separated by :: 
; the class name contains the string "Home" and a string 
representing the subject class; the method name contains the 65 
string "find", and the code body contains an object query 
method invocation expecting exactly one parameter which is 



a string representing the query to be performed. It is to be 
appreciated that other recurring patterns designated as "find" 
methods are possible and even likely. 

Briefly, the "object query technique" pattern recognized 
in each of these samples is as follows: the method invocation 
of interest is contained within the body of a "find" method 
code body; the method invocation of interest returns a value 
that matches that returned by the "find" method itself; the 
method invocation of interest takes exactly one parameter 
which is a string representing the query to be performed. It 
is to be appreciated that other recurring patterns designated 
as "object query technique" methods are possible and even 
likely. 

The following blocks of program code illustrate code 
augmentation for each of the above "find" methods, 
respectively, for searching a cache of query results in 
accordance with one aspect of the present invention: 



classA::object(] classAHomc::findByAttributel (string al){ (4a) 
classA::object[] retV&l; 
string__var sQuery » "attribute 1 + al; 
string_var sName - "classAHome::fmdByAttributer'; 
retVal- (classA::object(l)qCache::lookup(sNarne, iDataObject, 
"eval ",sQuery); 
return(retVai); 

} 

classA::object[] classAHome::findbyAUribute2(int a2) { (5a) 
classA::objcct[] ret\&l; 

string_var sQuery = "attribute2 «" + intToString(a2); 
string_var Sname = "cl ass AHome::findBy Attribute 2"; 
retVal= (classA::object[DqCache::lookup(sName, iDataObject, 
"eval sQucry); 
return (retVal); 

} 

classA::object[J classAHome::findByAttribute3(classB::objecta3) { (6a) 
classA::object{] ret\&l; 

string_var sQuery = "attribute3 ==" + objectTold(a3); 
string_var sName « "classAHome::fhidByAttribute3"; 
retVal « (classA:object[])qCache::lookup(sName f iDataObject, 
"eval sQuery); 
return(retVal); 

} 

classA::object[] (7a) 
classAHome"firidByAttributelAndAttribute2(string al, int a2) { 

classA::object[] ret\al; 

string_var sQl = "attribute 1 ==" + al; 

string_var sQ2 "attribute 2 ==" + intToString(a2); 

string_var sQuery =• sQl + "AND" + sQ2; 

string var sName = " class AHorne::findByAttributel And Attribute 2"; 

retVal = (classA::object(DqCache::lookup(sName, iDataObject, 
"eval", sQuery); 
return(retval); 

} 

classA::object(] classAHome::findByAttributel OrAttribute2(string (Sa) 
al, int a2) { 

class A "object retVal; 

string_var sQl - "attribute! — " + al; 

string_var sQ2 - "attribute2 -«" + intTo String (a2); 

string__var sQuery * sQl + "OR" + sQ2; 

string_var sName » "classAHome:findByAttributclOrAttribute2"; 
retVal » (classA::object(DqCache::lookup(sNamc, iDataObject, "cval", 
sQuery); 
return(retVal); 

} 



As shown in each of the blocks of program code, the original 
programmer supplied source code is augmented with addi- 
tional code (shown in italics) in accordance with step 307 of 
FIG. 3 in order to search cached query results (in accordance 
with step 205 of FIG. 2). Specifically, during the ALPACA 
process, the original programmer supplied blocks of source 
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code (4)-(8) are transformed into cached query enabled code 
blocks (4a)-(8a) ) respectively, which is compiled into the 
program. At run-time, each cached query request is carried 
out according to steps 204-209 of FIG. 2. 

By way of example, the run- time process of qCach- 
e::lookup for the above-illustrated augmented program 
block (7a) will now be described in further detail with 
reference to the method depicted in the flow diagram of FIG. 
4. Initially, a cache key is calculated (step 400) partly based 
upon the query at hand. For this example, assume that the 
query at hand, specifically the run-time value of sQuery, is 
the following Object-Oriented Structure Query Language 
(OOSQL)-like statement: 

"attribute! LIKE <a!Value>AND attribute2 UKE<a2Value> ,? ; 

where <al Value> and <a2Value> represent the actual values 
(in stringified form) of alvalue and a2Value, respectively. 
Assume further that the calculated cache key is the fully 
qualified method name: 

"classAHome::findBy Attribute! And Attribute^' 

concatenated with ":=" followed by the run-time value of 
sQuery. In this example, the resulting cache key is: 

"classAHome::findByAttributelAndAttribute2:-atttibutel LIKE 
<a 1 Value > AND attribute2 LIKE <a2Value>*\ 

The calculated cache key (from step 400) is used to 
interrogate the cache (step 401) in order to make the 
determination as to whether or not the corresponding query 
result for this particular method invocation of 
classAHome::findByAttributelandAttribute2 already exists 
in the cache. 

If it is determined that the cache does contain results for 
the query (affirmative result in step 401), the program flows 
directly to replicate cached results (step 402). Next, the 
replicated results are returned (step 403) and the processing 
for this query is complete. On the other hand, if it is 
determined that the cache does not contain results for the 
query (negative determination in step 401), the program 
flows to obtain the results based upon the original query 
iDataObject->eval(sQuery) (step 404) in the standard 
manner, absent the efficient cache described herein. The 
query results obtained are then placed into the cache (step 
405) using the calculated cache key (from step 400). 

Program control then proceeds to determine attribute 
dependencies (step 406). Specifically, the attribute depen- 
dencies are determined by examining the query at hand and 
locating attribute references. By way of the above example, 
the recognized attributes from sQuery are "attributel" and 
"attribute2", and <alvalue>and <a2Value>are their respec- 
tive corresponding values in stringified form. This informa- 
tion is used to add dependencies (step 407) to the newly 
cached query results (that were stored in the cache step 405). 
These dependencies are referenced whenever one of the 
following events occur: 

classA::attributel(sVal); 
classA: »ttributc2(sVal); 
classAHome::create( ); or 
classAHome::delete(target); 

and the cache is updated appropriately, as necessary. Once 
the dependencies have been added, program flow then 
continues at (step 401). 
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In accordance with the present invention, the following 
set of query keys (ql-q5) and set of dependencies (dl—dS) 
are examples of what might ultimately be produced subse- 
quent to at least one invocation of each qCache::lookup 
5 method in the above sample program code blocks (4a)~(8a) 
given the parameters string al Value, int a2 Value, and class- 
B:: object a3 Value, as appropriate: 

ql=ClassAHome::flndByAttributel:=attributel LIKE <alValue>; 

]0 q2=C]assAHome::fiadByAtlribute2:=aUribute2 LIKE <a2Value>; 

q3=ClassAHome::findByAttribute3:«attribute3 LIKE <a3 Value >; 

q4-classAHome::findByAttributelAndAttribute2:-attributel LIKE 
<al Value>AND atlribute2 LIKE <a2Value>; and 

15 

q5»cIassAHotnc::&ndByAttributclOrAttributc2:=atlributcl LIKE 
<alValuc>OR attributc2 LIKE <a2Valuc>; 

dl=classA::auributel :=<al Wue>; 
20 d2=classA::attribute2:*<a2Value>; 

d3=classA::attribute3:=<a3\&lue>; 

d4-classA::crcate; and 
^ dS»classA::dclctc. 

Referring now to FIG. 5, a diagram illustrates an object 
dependence graph showing the relationships between the 
query keys (ql-q5), each representing a specific query 

30 result, and the qcache:: lookup manufactured dependencies 
(dl-d5). These relationships are referred to whenever a "set 
attribute", "create", or "delete" method occurs in order to 
update the cache in accordance with the teachings herein, as 
necessary. As illustrated in FIG. 5, the dependencies for ql 

35 are dl, d4, and d5 (or, referring to the above illustrated query 
keys and dependencies, the cached query result for 
"attributel LIKE <alValue> J " potentially becomes invalid 
only whenever classA::attributel(sVal), or classA::create( ), 
or classA::delete( ) method is invoked). It is to be under- 

40 stood that the dependencies are generated by program analy- 
sis as described above in step 407 of FIG. 4. 

Thus, continuing the above example, if an instance of a 
classA object has its attributel value change from a 1 Value to 
some other value, say blvalue, because of classA:: attributel 

45 (bl Value), then the object dependence graph is consulted to 
determine that query results ql and q4, which depend on 
dependency dl, must be at Least flushed from the cache 
(whereas q5, which also depends on dl, may or may not be 
flushed from the cache due to xl as discussed below). The 

50 cache might be repopulated with adjusted ql and q4 results, 
depending upon various run-time factors. 

Similarly, if an instance of a classA object is deleted 
because of classAHome::delete(target), then the object 
dependence graph is consulted to determine that query 

55 results ql, q2, q3, q4, and q5, which depend on dependency 
d5, might need to be flushed from the cache, depending upon 
the attribute values of the deleted target object. The cache 
might be repopulated with adjusted query results, depending 
upon various run-time factors. 

60 Furthermore, with respect to q5, if an instance of a classA 
object has both its attributel and/or attribute2 values change 
to some other values, say clValue and/or c2Value 
respectively, because of classA:: attributel (clValue) and/or 
classA: :attribute2(c2 Value), then the object dependence 

65 graph is consulted to determine if query result q5, which 
depends on dependency dl AND dependency d2 together, as 
shown by xl, must be flushed from the cache. It is to be 
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understood that other query results (e.g., ql, q2, q3 and/or 
q4) may be flushed/repopulated independent of what occurs 
to the q5 cached query result. 

In the case where only attributel changed to cl Value 
(presuming cl Value does not qualify the object for the query s 
result) and the value of unchanged attribute2 continues to 
qualify the query result, the cache remains unchanged with 
respect to q5. However, other query results may be flushed/ 
repopulated. Similarly, in the case where only attribute2 
changed to value c2Value (presuming c2Value does not 10 
qualify the object for the query result) and the value of 
unchanged attributel continues to qualify the query result, 
the cache remains unchanged with respect to q5. Again, 
other query results may be flushed/repopulated. But in the 
case where both attributel and attribute2 change, and then 15 
neither qualifies the object for the query result, then the 
query result is flushed from the cache. The cache might be 
repopulated with adjusted query results, depending upon 
various run-time factors. 

It is to be understood that although the above examples 20 
illustrate a particular way to handle "and" and "or" opera- 
tions with respect to the query results cache, one of ordinary 
skill in the art may envision other variations on how to 
handle these particular operations, as well as other opera- 
tions and combinations of operations. 25 

In addition, it is to be appreciated by one skilled in the art 
that when a cached query result is found to be obsolete, it is 
sometimes possible and/or desirable to update the cache (as 
noted above) instead of invalidating/rep opulating the cache. 
For example, assume an object is deleted. Ordinarily, a 30 
particular query result would be purged from the cache, and 
the cache may be repopulated with the new result for that 
query. Updating the cache is an alternative possibility, 
whereby the deleted object can be removed from the query 
result in the cache. Similarly, for a create method, the newly 35 
created object could be added to the appropriate query 
results. 

It is to be appreciated that other techniques for maintain- 
ing dependency relationships between cached entities and 
underlying data may be employed in the present invention. 40 
In addition, a more generalized method which may be 
employed for maintaining dependency relationships is the 
data update propagation (DUP) method described in U.S. 
Pat. No. 6,026,413, issued on Feb. 15, 2000, entitled: 
"Determining How Changes to Underlying Data Affect 45 
Cached Objects," which is commonly assigned and incor- 
porated herein by reference. This method may be employed 
to determine how changes to underlying data affect cached 
query results in conjunction with the present invention. The 
DUP algorithm (which is also disclosed in "A Scalable 50 
System for Consistently Caching Dynamic Web Data" by J. 
Challenger, A. Iyengar, and P. Dantzig in Proceedings of 
IEEE INFOCONT99, March, 1999), is a method for iden- 
tifying cached entities which become stale as a result of 
changes to underlying data on which the cached entities 55 
depend, such as databases. This method allows stale cached 
entities to be either invalidated or updated directly in the 
cache without having to first perform invalidation. For 
instance, the DUP algorithm may be employed to identify 
cached objects affected by database changes, whereby the 60 
DUP algorithm maintains correspondences between objects 
(which are defined in the cited references as items which 
may be cached) and underlying data, which correspond to 
parts of the database. 

It is to be further understood that the present invention is 65 
not restricted to the specific types of query results described 
above and that a variety of different entities (other than 
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query results) may be cached and managed in accordance 
with the teachings herein. Moreover, notwithstanding that 
the above illustrative embodiments discuss how program 
analysis can applied to make decisions about caching and 
invalidating queries, one of ordinary skill in the art can 
envision a variety of implementations utilizing program 
analysis to assist in performing cache transactions. 

For example, referring to FIG. 6, a flow diagram illus- 
trates a method for managing cachable entities in accordance 
with an embodiment of the present invention. It is to be 
understood that the flow diagram of FIG. 6 represents a 
general approach for using program analysis for aiding in 
making cache decisions (and that the above illustrative 
embodiments are particular examples of the methodology 
embodied in FIG. 6). With this method, a program is 
analyzed to identify or otherwise detect one or more state- 
ments (if they exist) which may modify a value of one or 
more cachable entities (e.g, an object, image file, we bp age, 
etc.) during run-time (step 600). For each of the detected 
statements (if any), a probability is determined which rep- 
resents the likelihood that the detected statements will be 
executed (i.e., the likelihood that one or more cachable 
entities will change due to execution of the statements) (step 
601). For example, if a statement is executed outside of a 
conditional branch in a program, the probability that the 
statement will execute is often 1. If, on the other hand, a 
statement executes within a conditional branch (e.g., if (y>0) 
then x«a*b) the probability that the statement will execute 
can often be determined from program analysis, In the 
previous example, the compiler might have determined 
through analysis that "y" is extremely likely to be positive. 
If so, it would conclude that x has a high probability of 
changing. 

To determine if a cache transaction will be performed 
(e.g., inserting an object in cache or deleting or updating a 
cached object), a determination is made as to whether the 
probability of change (of one or more entities) meets a 
predefined threshold (step 602). If it is determined that the 
likelihood of change exceeds the threshold (affirmative 
determination in step 602), the system may be in favor of not 
caching one or more uncached entities and/or be in favor of 
invalidating or updating one or more cached entities (step 

603) . On the other hand, if it is determined that the likeli- 
hood of change does not exceed the threshold (negative 
determination in step 602), the system may be in favor of 
caching one or more uncached entities and/or not be in favor 
of invalidating or updating one or more cached entities (step 

604) . 

It is to be appreciated that the process depicted in FIG. 6, 
may be slightly modified to provide another method for 
managing cachable entities in accordance with the present 
invention. In particular, one or more statements may be 
added to the program (in step 600), some of which being 
utilized to determine the likelihood of change. In this 
method, step 601 would be performed when the program 
executes. 

It is to be understood that there are a number of extensions 
and generalizations to the method depicted in FIG. 6. For 
instance, the method just described uses program analysis to 
calculate the desirability of, e.g., caching an entity based on 
its expected lifetime. It is possible to use program analysis 
for calculating the desirability of caching an entity based on 
other criteria such as cost to fetch or materialize, expected 
frequency of access, and size. For example, the method can 
be adapted to favor caching objects which are expensive to 
fetch or materialize over objects which are less expensive to 
fetch or materialize. In order to accomplish this, the program 
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analysis (in step 600) could be implemented to identify or 
otherwise detect one or more statements which materialize 
or fetch a value of one or more entities. Then, a cost for 
materializing or fetching one or more entities may be 
estimated (in step 601) based on the one or more detected 5 
statements. Then, a determination can be made (in step 602) 
as to whether the estimated cost exceeds a threshold. If so, 
then the system would favor caching the entities (in step 
604). If not, then the system would favor not caching the 
entities (in step 603). 

A more sophisticated implementation of step 602 would 
consider several factors in making caching decisions includ- 
ing but not limited to access frequency, size, cost for 
materializing or fetching, and lifetime. An exemplary 
embodiment of such an implementation is described in U.S. 
patent application Ser. No. 08/958,506, entitled: 'A New ]5 
Algorithm for Cache Replacement", filed on Oct. 27, 1997 
and commonly assigned. 

It is to be further appreciated that the methods discussed 
herein may be utilized in conjunction with cache replace- 
ment algorithms. Cache replacement algorithms are used to 20 
determine which entities should be excluded from a cache 
when the cache contains insufficient space to store all 
entities. Several references on cache replacement algorithms 
exist in the literature including "Cost- Aware WWW Proxy 
Caching Algorithms" by Pei Cao and Sandy Irani, Proceed- 2 s 
ings of USITS '97, Monterey, Calif., December 1997. 

Although illustrative embodiments have been described 
herein with reference to the accompanying drawings, it is to 
be understood that the present system and method is not 
limited to those precise embodiments, and that various other ^ o 
changes and modifications may be affected therein by one 
skilled in the art without departing from the scope or spirit 
of the invention. All such changes and modifications are 
intended to be included within the scope of the invention as 
defined by the appended claims. 

What is claimed is: 35 

1. A method for managing a plurality of cachable entities, 
comprising the steps of: 

analyzing program code to determine if there is at least 
one statement which may affect a desirability of per- 
forming at least one cache transaction, wherein the at 40 
least one statement is a statement that modifies a value 
of at least one cachable entity, and wherein the desir- 
ability is based on an expected lifetime of the at least 
one cachable entity; 

determining the desirability of performing the at least one 45 
cache transaction based on a probability that the at least 
one statement will execute; and 

performing the at least one cache transaction if said 
desirability is greater than or equal to a threshold. 

2. The method of claim 1, wherein the desirability of 50 
performing the at least one cache transaction is based on one 

of a frequency of access of at least one cachable entity, a size 
of at least one cachable entity, a time to one of fetch and 
materialize at least one cachable entity, a lifetime of at least 
one cachable entity, and a combination thereof. 55 

3. The method of claim 1, wherein the step of performing 
at least one cache transaction comprises one of storing at 
least one cachable entity in a cache, invalidating at least one 
cachable entity stored in a cache, updating at least one 
cachable entity stored in a cache, and a combination thereof. 60 

4. The method of claim 1, further comprising the step of 
augmenting the program code with additional code to assist 
in determining the desirability of performing the at least one 
cache transaction. 

5. The method of claim 1, further comprising the step of 65 
augmenting the program code with additional code to per- 
form the at least one cache transaction. 



6. The method of claim 3, wherein at least one of the step 
of invalidating the at least one cachable entity stored in the 
cache and the step of updating the at least one cachable 
entity stored in the cache comprise the step of performing 
data update propagation (DUP). 

7. The method of claim 1, wherein the at least one 
statement is one of source code, assembly code, machine 
code, and structured query language (SQL) code. 

8. The method of claim 7, wherein the at least one 
statement in the SQL code includes at least one SET 
statement. 

9. The method of claim 1, wherein the cachable entities 
include query results. 

10. The method of claim 1, wherein the analyzing step 
comprises the steps of: 

detecting at least one query statement for retrieving at 
least one of the cachable entities from a cache; 

generating a query key formal; and 

augmenting the program code with additional code for 

calculating a query key in accordance with the query 

key format. 

11. The method of claim 10, wherein the step of perform- 
ing at least one cache transaction comprises the steps of: 

executing the augmented code to calculate the query key; 

searching the cache using the query key; and 

retrieving at least one cachable entity stored in the cache 
if the cachable entity corresponds to the query key. 

12. The method of claim 11, further comprising the steps 

of: 

processing the at least one query statement to retrieve at 
least one of the plurality of cachable entities, if there 
are no cachable entities in the cache which correspond 
to the query key; 

storing the at least one retrieved cachable entity in the 

cache using the query key; and 
associating at least one dependency with the at least one 

retrieved cachable entity. 

13. The method of claim 1, wherein the at least one 
statement is a type that one of creates at least one cachable 
entity, deletes at least one cachable entity, and modifies a 
value of at least one cachable entity, wherein the analyzing 
step comprises the steps of: 

generating an invalidation key format in accordance with 
the type of the at least one statement; and 

augmenting the program code with additional code for 
calculating an invalidation key in accordance with the 
generated invalidation key format. 

14. The method of claim 13, wherein the step of perform- 
ing at least one cache transaction comprises the steps of: 

executing the augmented code to calculate the invalida- 
tion key; and 

invalidating at least one cachable entity stored in the 
cache that corresponds to the invalidation key. 

15. The method of claim 14, wherein the step of invali- 
dating at least one cachable entity comprises one of purging 
the cachable entity from the cache, purging the cachable 
entity from the cache and repopulating the cache, and 
updating the cache. 

16. The method of claim 1, wherein the step of performing 
at least one cache transaction comprises the step of initial- 
izing a cache. 

17. A program storage device readable by a machine, 
tangibly embodying a program of instructions executable by 
the machine to perform method steps for managing a plu- 
rality of cachable entities, the method steps comprising: 



05/13/2004, EAST Version: 1.4.1 



US 6,725,333 Bl 



17 



18 



15 



analyzing program code to determine if there is at least 
one statement which may affect a desirability of per- 
forming at least one cache transaction, wherein the at 
least one statement is a statement that modifies a value 
of at least one cachable entity, and wherein the desir- $ 
ability is based on an expected lifetime of the at least 
one cachable entity; 

determining the desirability of performing the at least one 
cache transaction based on a probability that the at least 
one statement will execute; and a0 

performing the at least one cache transaction if said 
desirability is greater than or equal to a threshold. 

18. The program storage device of claim 17, wherein the 
desirability of performing the at least one cache transaction 
is based on one of a frequency of access of at least one 
cachable entity, a size of at least one cachable entity, a time 
to one of fetch and materialize at least one cachable entity, 
a lifetime of at least one cachable entity, and a combination 
thereof. 

19. The program storage device of claim 17, wherein the 
instructions for performing at least one cache transaction 20 
include instructions for one of storing at least one cachable 
entity in a cache, invalidating at least one cachable entity 
stored in a cache, updating at least one cachable entity stored 

in a cache, and a combination thereof. 

20. The program storage device claim 17, further includ- 25 
ing instructions for augmenting the program code with 
additional code to assist in determining the desirability of 
performing the at least one cache transaction. 

21. The program storage device of claim 17, further 
including instructions for augmenting the program code with 30 
additional code to perform the at least one cache transaction. 

22. The program storage device of claim 21, wherein the 
instructions for at least one of invalidating the at least one 
cachable entity stored in the cache and updating the at least 
one cachable entity stored in the cache include instructions 35 
for performing data update propagation (DUP). 

23. The program storage device of claim 17, wherein the 
at least one statement is one of source code, assembly code, 
machine code, and structured query language (SQL) code. 

24. The program storage device of claim 23, wherein the 40 
at least one statement in the SQL code includes at least one 
SET statement. 

25. The program storage device of claim 17, wherein the 
cachable entities include query results. 

26. The program storage device of claim 17, wherein the 45 
instruction for performing the analyzing step include 
instructions for performing the steps of: 

detecting at least one query statement for retrieving at 
least one of the cachable entities from a cache; 

generating a query key format; and 

augmenting the program code with additional code for 
calculating a query key in accordance with the query 
key format. 

27. The program storage device of claim 26, wherein the 5S 
instructions for performing at least one cache transaction 
include instructions for performing the steps of: 

executing the augmented code to calculate the query key; 
searching the cache using the query key; and 
retrieving at least one cachable entity stored in the cache <so 
if the cachable entity corresponds to the query key. 

28. The program storage device of claim 27, further 
including instructions for performing the steps of: 

processing the at least one query statement to retrieve at 
least one of the plurality of cachable entities, if there 65 
are no cachable entities in the cache which correspond 
to the query key; 
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storing the at least one retrieved cachable entity in the 

cache using the query key; and 
associating at least one dependency with the at least one 

retrieved cachable entity. 

29. The program storage device of claim 17, wherein the 
at least one statement is a type that one of creates at least one 
cachable entity, deletes at least one cachable entity, and 
modifies a value of at least one cachable entity, wherein the 
instructions for performing the analyzing step include 
instructions for performing the steps of: 

generating an invalidation key format in accordance with 
the type of the at least one statement; and 

augmenting the program code with additional code for 
calculating an invalidation key in accordance with the 
generated invalidation key format. 

30. The program storage device of claim 29, wherein the 
instructions for performing the at least one cache transaction 
include instructions for performing the steps of: 

executing the augmented code to calculate the invalida- 
tion key; and 

invalidating at least one cachable entity stored in the 
cache that corresponds to the invalidation key. 

31. The program storage device of claim 30, wherein the 
instructions for invalidating at least one cachable entity 
include instructions for performing one of purging the 
cachable entity from the cache, purging the cachable entity 
from the cache and repopulating the cache, and updating the 
cache. 

32. The program storage device of claim 17, wherein the 
instructions for performing the at least one cache transaction 
include instructions for initializing a cache. 

33. Asystem for managing a plurality of cachable entities, 
comprising: 

a program analyzer to analyze program code and deter- 
mine if there is at least one statement which may affect 
a desirability of performing at least one cache 
transaction, wherein the at least one detected statement 
is a statement that modifies a value of at least one 
cachable entity, and wherein the desirability is based on 
an expected lifetime of the at least one cachable entity, 

the program analyzer determining the desirability of per- 
forming the at least one cache transaction based on a 
probability that the at least one statement will execute; 
and 

a cache manager for performing the at least one cache 
trans action if said desirability is greater than or equal to 
a threshold. 

34. The system of claim 33, wherein the desirability of 
performing the at least one cache transaction is based on one 
of a frequency of access of at least one cachable entity, a size 
of at least one cachable entity, a time to one of fetch and 
materialize at least one cachable entity, a lifetime of at least 
one cachable entity, and a combinaiion thereof. 

35. The system of claim 34, wherein the cache manager 
performs one of storing at least one cachable entity in the 
cache, invalidating at least one cachable entity stored in the 
cache, updating at least one cachable entity stored in the and 
a combination thereof. 

36. The system of claim 34, wherein the cache manager 
augments the program code with additional code to assist in 
determining the desirability of performing the at least one 
cache transaction. 

37. The system of claim 34, wherein the cache manager 
augments the program code with additional code to perform 
the at least one cache transaction. 
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